Computing systems store vast amounts of data. The data can be stored on mass storage devices, for example, magnetic or optical disks. The mass storage devices can be managed by a storage system including a computing device such as a network storage controller. The network storage controller can allow file level access, block level access, or both, to data stored within the mass storage devices. Such mass storage devices may be organized into groups of drives, such as into a redundant array of independent disks (RAID). The non-volatile mass storage devices may be aggregated and divided into volumes including logical units. Each logical unit within a volume can be identified by a logical unit number (LUN). Data is stored to and retrieved from the logical units by the hosts as though the logical units were locally attached to the hosts as mass storage devices.
A volume and all included logical units can be backed up by creating a persistent point-in-time image (PPI) of the volume. A PPI is typically creates as read-only, however a PPI can be created as both readable and writeable. Such a read-write PPI can be used as a “writeable PPI.” Typically, a writeable PPI is created by a user or entity having permission to create, modify, and delete the writeable PPI. One or more hosts (e.g., clients) may access the writeable PPI via a network, such as by mapping to the logical units within the writeable PPI and reading from and writing to the logical units as virtual mass storage devices.
A “writeable PPI” can be used for a variety of purposes, for example, to test and/or change data without interrupting clients using the data on the volume from which the writeable PPI is created. In order to access the writeable PPI for reading and writing data, a client creates a file system. A “file system” is an executable process, such as software for execution on a computing device. The file system is used to manage conventional “files,” and/or blocks of data.
When the client has completed its purpose, e.g., testing data, the client can delete the file system. The deletion of the writeable PPI from the storage system typically follows deletion of the file system. The deletion has many purposes, for example, to avoid unnecessary use of storage space, which is often a limited resource. However, at times one or more conditions exist indicating that the writeable PPI has not reached the end of its life cycle.
Several conditions are described by way of example: clients or entities other than the client creating the writeable PPI may have begun using the writeable PPI. Alternatively, new logical units could have been created in the writeable PPI, indicating that the writeable PPI is still in use. Further, new PPIs derived from the writeable PPI may have been created. Also, clients could be directly mapped to the logical units themselves. Another example of a condition presents itself when a client other than the client that created the writeable PPI requests deletion of the writeable PPI. The request could indicate malicious or accidental deletion to the detriment of the creator of the writeable PPI.
In an environment having numerous volumes, deletion of writeable PPIs can impact performance for many clients or entities. Under any of these conditions described above, and under other conditions not described, deletion could result in undesirable data loss, and could interrupt the clients or other entities. Therefore, the deletion of the writeable PPI should not be done if the writeable PPI has not reached the end of its life cycle.